The service provider market has moved up the value chain from pure connectivity services to deliver value-added and revenue generating services. The business model of a service provider, which was initially driven by minutes of use, is being increasingly replaced by data traffic, generated by users that access either internal services owned and maintained by the service provider itself or external services not maintained by the service provider but accessed through the service provider platform. In addition to growing their customer bases, service providers are now looking to increase the average revenue per user to boost revenues. More compelling services such as content, commerce, and other applications promise higher profit margins, improved customer retention, and greater customer satisfaction. However, managing and distributing these third-party services or content services present significant challenges to service providers. Therefore, the service provider plays a key role since it is the intermediary between the end-user and the internal or external services. Its privileged position allows the service provider to not only provide just “simple” access but added value services such as security, single sign-on, billing, location, etc. at the condition that it cannot be “bypassed” by the user.
In most cases, external services and partners that provide resources will do it for authenticated users only, meaning that they maintain and enforce the authentication and authorization of these users using their own user registry. Therefore, multiple authentication points may exist thus requiring the end-user to maintain multiple user IDs and passwords, and be prompted to authenticate multiple times in order to be able to access his personalized services. Obviously, this represents a fastidious step for the end-user to enter several times username(s)/password(s) in order to access the Web services. As such, the service provider might loose any credibility towards its end-users if it does not provide a solution to this problem. A solution is to provide a “Single Sign On” feature to their end-users giving them the possibility to use the same User Id and password for all services, whether internal or external, that require authentication. With this feature, user authentication only needs to be done once to access services requiring a user Id and password.
At connection time, the service provider asks the end-user to identify himself as an authorized user by responding to a username/password prompt displayed on the user device in order to give end-users the benefit of personalized services and resources according to the end-users choices and preferences. As already mentioned, these personalized services and resources can be either internal services managed and maintained by the service provider or external services provided by content provider partners.
The service providers and content providers partners have to come to an agreement on how end-user credentials should be passed from the service provider to the partners. The HTTP protocol is the transport protocol used for each communication involved, in one hand in the exchanges between the device being used to access the internal or external services provided by the service provider which is typically a Web browser and the service provider platform, and in other hand between the service provider and its service and the partners. Different techniques exist today such as the Basic HTTP Authentication exchange defined in the HTTP standard, HTTP cookies, customized HTTP headers, etc. These techniques can be used to perform such integration around a single sign-on. Unfortunately, these solutions require business development and cost on each side if partners are to directly trust the authentication done by the service provider platform.
The service provider is the intermediary between the end-user and the internal or external services. Thanks to its privileged position, the service provider uses in most cases an HTTP proxy component deployed in its infrastructure, which all end-users must go through, and which acts as a central authentication point for all end-users who wish to access personalized internal and external services and resources.
Two well known and spread authentication methods on the Internet are the HTTP Basic Authentication and forms-based authentication (e.g., an HTML form sent to the end-user prompting the user to enter a username/password), both over a normal or secure encrypted connection. Although performing single sign-on with Basic Authentication is relatively easy (and most of the HTTP proxies in the market already support single sign-on to back-end application servers representing external services or content provider partners using the HTTP Basic Authentication as described in the HTTP specification) most servers choose not to use it as a means of authentication, primarily because the user interface is unsophisticated and set by the Web browser and also because it is limited to a single hostname. Forms-based authentication is much more widely used because it is more flexible. Unfortunately, it is this very flexibility that makes single sign-on to form-based systems so difficult to handle insofar as the forms being used are various and different in function of the servers, thereby requiring a development cost.